System design and development is known in the art. A customer will typically contract with a designer/manufacturer to design and develop a system. The customer typically provides top-level system requirements within the contract. However, these requirements describe the performance of the entire system, and systems are designed and developed as individual elements (e.g., circuit cards, software packages, etc.). Hence, requirements development is the process of defining the requirements of each of the individual system elements such that they all work together to form an optimum system level solution.
Good requirements development is critical to the success of any development program. Complex systems require many different system elements to be developed at the same time and still be functional as large systems once integrated together. Hence, providing the detailed design requirements to each lower level element designer is crucial to the lower level designers' ability to create a good design the first time.
Traditionally, development programs have used a layered approach to generating lower level requirements for a system. As is illustrated in FIG. 1, such traditional approach starts with the top-level system requirements (typically provided by the customer contract) and a specification tree of the system to be developed. The top-level requirements are analyzed and flowed down to the next level in the specification tree, resulting in the development of the second level specifications. Next, the second level specifications are analyzed and flowed down to the next level in the specification tree, resulting in the development of the third level specifications. This process is then repeated until all the requirements have been flowed to the lowest level in the specification tree. The designers then use these specifications to develop the individual system elements.
As an example, FIG. 1 illustrates a typical specification tree, in this case relating to the development of a weapons system. The top-level requirements typically come from the customer contract. Next, specifications are developed for each major sub-program (e.g., launch platform specification, missile specification, and launcher specification). Next, the major system element specifications for each sub-program are developed based on flowing down from the previous level specifications. In FIG. 1, only the major system elements for the missile specifications are shown (e.g., warhead specification, fuze specification, guidance section specification, etc.), although it will be appreciated that each sub-program will have it's own major system element specifications. In the fourth level, the major system element specifications from the third level are flowed down to define the specifications for the next level of system elements. In the case of the guidance section specification, the next level of system elements includes seeker specification, electronic unit specification, sensor assembly specification, etc.
The above process is repeated until the last level of the program specification tree is populated. In the case of the electronics unit specification of the guidance section specification, the last level may include circuit card No. 1 specification and circuit card No. 2 specification, for example. Again, while each system element has not been fully expanded at each level in FIG. 1 for sake of clarity, it will be appreciated that each system element will likely have additional system elements dependent therefrom in lower levels.
Unfortunately, however, poor requirements development frequently negatively impacts the success of a complex development program. Bad or late requirements can cause the designer of a lower level system element to design to the wrong requirements at that level, thus creating a design that, when integrated with the other system elements, does not allow the system to meet the top level requirements. This can cause the particular system element, and possibly other system elements, to have to be redesigned, often resulting in massive cost and development schedule impacts.
With the above-described traditional layered approach, the emphasis is on each horizontal level of the program specification tree. This leads to one drawback wherein the approach is slow to get the requirements to the lowest levels of the specification tree. The layered approach requires the lowest level requirements to pass through many levels before the lowest level system element requirements can be developed.
Another drawback is that complex requirements are usually analyzed multiple times during flow-down from one level to the next. For example, a first set of analyses is done to determine the allocation of requirements at the second level of the specification tree, then again to determine the allocation between the elements at the next level, and so on. Each time the analysis is repeated in increasing level of detail, in order to refine the requirements as they flow down through the system. However, repeating the analysis many times can be inefficient. Also, there is a considerable likelihood of discontinuities between the analyses. In some cases the analyses are done completely up front, but then can be misunderstood later, forgotten, or even lost later in the requirements flow-down process.
Yet another drawback is that margins tend to be managed independently at each level of the flow-down. This can cause a lack of an integrated margin management approach across all levels of the specification tree. This lack of an integrated approach can cause more stringent requirements than necessary. Still another drawback is that if the requirements that were flowed down are found to be unachievable by the lower level system element designers, this is not discovered until late in the requirements development process. Thus, this often results in specification changes to the design element found to be unachievable. However, since this usually also results in a redistribution of requirements across other system elements, the specifications and designs of other system elements are also often impacted.
In view of the aforementioned shortcomings associated with traditional level-by-level requirements development, there is a strong need in the art for an approach which avoids delays in getting the proper requirements to the lowest level of the specification tree. Moreover, there is a strong need for an approach which avoids inefficiencies associated with multiple analyses of the same requirements. In addition, there is a strong need for an approach which avoids excessive margins that can result in unachievable requirements at the lower levels and/or overly stringent requirements.